Object request brokers (ORBs) provide for access to software objects which may reside remote to a requester, such as in a different software process, on a different machine in a network or on a different network altogether. Standards define how ORBs can be implemented and how they interact to support different languages, networks and computing platforms. The Common Object Request Broker Architecture (CORBA®, a registered trademark of the Object Management Group) is a dominant standard architecture which uses a language-neutral format for messages exchanged between ORBs known as the General Inter-ORB Protocol (GIOP).
Conversion from language specific and machine specific data and message formats is expensive in terms of resource utilization. It is a well established optimization to allow local object accesses to bypass much of the conversion process when certain, specific, conditions are satisfied to confirm that an object access is indeed local. When an application is to be distributed over several processes or machines (such as several computer systems arranged into a grid architecture), a distribution mechanism can be employed having an associated ORB to refer GIOP messages to appropriate target servers. For example, such a distribution mechanism might be employed to provide load balancing functionality between a set of servers. When such distribution mechanisms are employed, communication of GIOP request messages from a client computer system to a target server can involve many conversions of the request message between the GIOP format and an implementation-specific format. This results from the need to receive the message at the distribution mechanism itself, and subsequently dispatch the message from the distribution mechanism to a target server. Messages are required to take the GIOP format for communication between ORBs, such as across an Internet Inter-Operability Protocol (IIOP). However, for use by a message recipient or a message originator, such as a distribution mechanism or a target server, messages must be converted to an implementation-specific format. Such an implementation-specific format is a graph of Java® objects (Java is a registered trademark of Sun Microsystems Inc.), although any number of alternative implementation-specific formats can be used depending upon a particular computing platform.
FIG. 1 is a schematic diagram of a communication between a client computer system 100 and a target server computer system 124 in the prior art. The client computer system 100 includes client software 100′ and an ORB 100″. The client computer system 100 is communicatively connected to any number of other computer systems via an IIOP network 102. The client computer system prepares a message 104 in GIOP format for dispatch over the IIOP network 102 via the ORB 100″. Message 104 can be any GIOP message, such as a request message. The message 104 is received by an ORB 106 associated with the distribution mechanism 110. The message 104 is considered an incoming message from the point of view of a receiving distribution mechanism 110. Initially, at step 108, the ORB 106 converts the incoming message 104 into an implementation-specific format and provides the message 104 in implementation-specific format for processing by the distribution mechanism 110 itself. At step 112, the distribution mechanism 110 identifies an appropriate target server 124 for processing the incoming message 104, and instigates a process of communicating the incoming message 104 to the target server 124. Identification of an appropriate target server 124 can be based on the contents of the incoming message 104, such as a header of the incoming message. Prior to communication of the incoming message 104 to the target server 124 it is converted back into the GIOP format at step 116 by an ORB 114 associated with the distribution mechanism 110. It is required to be converted back to the GIOP format in order to be communicated to the target server 124 across the IIOP network 102. ORBs 106 and 114 associated with the distribution mechanism 110 can be identical, equivalent or indeed the same ORB. Subsequently, ORB 114 communicates the incoming message 104 to the target server 124 over the IIOP network 102.
On receipt of the incoming message 104 by the target server 124, the incoming message is initially processed by an ORB 120 associated with the target server which converts, at step 122, the incoming message 104 from its GIOP format to the implementation-specific format. Subsequently, at step 126 the target server 124 is finally able to process the substantive content of the message. For example, processing of a GIOP message can involve an invocation of an implementation object. Subsequently, the target server 124 determines that an outgoing message 142 is required to be returned to the client 100 as a reply message corresponding to the incoming message 104 (although not all incoming messages will necessarily warrant a reply). At step 128 the target server prepares the outgoing message 142 in the implementation-specific format for passing to the ORB 120. At step 130, the ORB 120 converts the outgoing message 142 in implementation-specific format to GIOP format for communication across the IIOP® protocol network 102 to the distribution mechanism 110. Once communicated across the IIOP network 102, the outgoing message 142 is initially processed by the ORB 114 associated with the distribution mechanism 110 which converts the outgoing message 142 in GIOP format to implementation-specific format at step 132 for processing by the distribution mechanism 110. The only role of the distribution mechanism at this point is to forward the outgoing message 142 to the ORB 106, which subsequently determines the target ORB 100″ at step 136. ORB 106 further converts the outgoing message 142 in implementation-specific format into GIOP format for communication across the IIOP® protocol network 102. Finally, the ORB 106 sends the outgoing message 142 in GIOP format to the client 100 across the IIOP® protocol network 102, for receipt by ORB 100″ of client 100.
Thus, it will be appreciated that such communication between a client 100 and a target server 124 via a distribution mechanism using ORBs and IIOP networks is resource intensive since messages must be converted numerous times. For example, the incoming message 104 is converted three times at steps 108, 116 and 122. Similarly, the outgoing message 142 is converted three times at steps 130, 132 and 138. These conversions constitute a significant processing overhead in distributed software using object request broker architectures.
One approach to alleviate the overhead of conversion is provided by CORBA. In this approach, GIOP messages are divided into two parts: a header; and a body. Forwarding decisions (e.g. Workload distribution) can be made upon inspection of the message header alone. Using this approach, on receipt at a distribution mechanism, a target server is identified based upon an inspection of the message header alone, and a reply message is sent to the client with information relating to the location of the appropriate target server. This approach reduces the amount of conversion of GIOP messages, since only the message header needs to be converted by the distribution mechanism. However, this approach requires further network communication to take place since the distribution mechanism communicates with the client to inform the client of the location of the target server, and the client must then restart its communication with the target server. Furthermore, there are additional disadvantages to this approach: the target servers must be accessible to the client (i.e. they cannot be in a secure or private part of a network); in the event that a reply message is required, the client must be accessible to the target server; and the distribution mechanism is able to only intervene to implement workload distribution functionality once for a client—once the client is informed of the location of the target server, it can communicate directly with the target server for all future requests.
It would therefore be advantageous to provide for effective GIOP communication between a client and a server employing a distribution mechanism with reduced message conversion and network traffic requirements, whilst providing that target servers and clients need not be accessible to each other and the distribution mechanism is able to intervene to implement workload distribution functionality on a per-request basis.